The present invention relates to fault coverage and specifically to fault coverage of interconnect in an FPGA.
Fault simulation is a well-known method of determining the quality of the test vectors used to verify the functionality of an application specific integrated circuit (ASIC). FIG. 1 illustrates a simplified flow diagram of fault simulation. In fault simulation, the operation of a gate-level model 103 of the ASIC is tested by a simulation program 102 using multiple sets of input signals 101, which include both stimuli (data) and control signals. Each set of input signals 101 is called a vector. Simulation program 102 generates the result 104, i.e. the output signals of model 103, for each vector.
Generally, model 103 is first tested for its fault-free response, i.e. the xe2x80x9cgoodxe2x80x9d response, then for induced fault responses. To induce a fault response, each node leading to logic in model 103 is individually held at a logic one. In this manner, irrespective of other input signals to the logic, that particular node can only carry a logic one. If a set of vectors can detect a change somewhere (i.e. that the signature no longer compares to the good response), then that stuck-at-one fault is detectable. Similarly, each node is individually held at a logic zero. If the set of vectors can detect each change, then each stuck-at-zero fault is detectable. In one embodiment including a library 105 of stuck-at-zero and stuck-at-one faults, each fault is inserted into model 103 one at a time.
In the above example, fault coverage would indicate what percentage of the universe of stuck-at-one faults and stuck-at-zero faults could be detected by the given set of vectors. In other words, fault coverage indicates the efficacy of the vectors in detecting each fault in a universe of potential faults. Thus, if stimuli and control 101 is able to detect every fault enumerated in fault library 105, then fault coverage approaching 100% has been achieved.
Fault simulation has been shown to correlate well with physical faults in the ASIC. Therefore, after simulation is complete, the ASIC is then tested with the same vectors used in the simulation. The response generated by the ASIC when exercised by these vectors is compared with the results generated from the fault free simulation. Any difference between the two indicates that a defect has been detected in the ASIC.
Clearly, as logic designs increase in complexity, merely creating the set of vectors can be extremely time consuming. Moreover, even assuming unlimited financial and personnel resources, fault coverage for a complex ASIC never reaches 100%. Thus, depending on the application of the ASIC, fault coverage in the range of 80% to 99% is typically considered acceptable.
To facilitate better fault simulation when an ASIC is being designed, test structures for DFT (design-for-test) could be added to the chip to provide the desired controllability and observability. Clearly, controlling a node to detect a stuck-at-one or stuck-at-zero fault is ineffective if one cannot observe its effect. Similarly, if one has an observation point, but cannot switch a value at a node, then fault simulation is impossible. Thus, controllability and observability typically are addressed at the same time.
In one embodiment, a test structure could include a plurality of flip-flops connected as a linear feedback shift register (LFSR). A LFSR can be used to generate data for exhaustive testing, psuedorandom testing, or pseudoexhaustive testing. A detailed description of these tests is provided in xe2x80x9cDigital Systems Testing and Testable Designxe2x80x9d, pages 457-482, by M. Abramovici et al., IEEE Press, 1990. In other embodiments, test structures such as pseudo random data generators or signature analyzers are used for DFT.
However, the increased controllability/observability of DFT comes at a significant cost. Specifically, the flip-flops of the test structure have considerably more transistors than flip-flops included in the functional logic. Thus, valuable real estate is used for test, which could otherwise be used for additional functional logic. Moreover, typical test structures also include multiplexers for selectively accepting data from a scan-in port or from the data. Therefore, during on-line DFT, these multiplexers can undesirably slow down normal functional operation.
Fault simulation and DFT are applicable to other types of integrated circuits, such as programmable logic devices. One popular type of programmable logic device is the field programmable gate array (FPGA). In fact, as technology improvements are realized, FPGAs are increasingly moving into previously ASIC-only applications. Unfortunately, physical resources are even more constrained on an FPGA than on an ASIC. Thus, generally the use of dedicated test structures on an FPGA is minimized. Additionally, in light of the programmable nature of an FPGA, providing the And user with the means to verify exhaustive fault coverage, i.e. for all possible configurations of the FPGA, is commercially impractical. Irrespective of these issues, users are requesting ASIC-type information for FPGAs, such as stuck-at-one fault coverage and stuck-at-zero fault coverage. Therefore, a need arises for providing fault coverage of an FPGA containing a specific user design.
The present invention provides fault coverage for the programmable interconnect of a programmable logic device (PLD). In the present invention, a user""s design is modeled, thereby determining the programmable interconnect path in the device. The present invention allows the programmable interconnect path to be preserved while ensuring the necessary control and observation of the fault tests.
Specifically, two derivative designs are generated based on the user""s design. In a first derivative design, the lookup tables (LUTs) in the function generators of the user""s design are configured to a first type of logic gate to detect stuck-at-one faults. In a second derivative design, the LUTs are configured to a second type of logic gate to detect stuck-at-zero faults. Thus, in either derivative design, a logic gate tree is formed. In one embodiment, all LUTs are implemented as either AND or OR gates.
Advantageously, in the two derivative designs, the synchronous elements of the user""s design are substantially preserved. In general, synchronous elements can be transformed, if necessary, to provide greater control during the fault tests. For example, flip-flops without initialization or reverse features can be transformed to provide these features. The input and output elements of the user""s design can also be transformed, if necessary. For example, a non-registered input or output element can be transformed into a registered input or output element, such as a flip-flop, to provide the desired controllability and observability. An output element providing signals to external devices can be further transformed to include tristating on its output, thereby allowing the tests to be run within a functioning system.
The method of the present invention includes the basic steps of determining the programmable interconnect path in the user""s design, configuring the function generators in the user""s design for a stuck-at-one or stuck-at-zero test, controlling the synchronous elements in the user""s design, providing a test vector, providing test clocks, and observing certain nodes in the design. In one embodiment, these nodes correspond to values stored by the synchronous elements. As noted above, certain features of the synchronous elements can be advantageously used to control the synchronous elements. For example, in one programmable logic device, each synchronous element (such as a flip-flop) can include an initialization terminal (INIT) that can force the flip-flop into a predetermined state (i.e. the value stored on the Q output terminal of the flip-flop) and a reverse terminal. (REV) that can force the flip-flop into a state opposite that of the predetermined state.
In the case of the stuck-at-zeros test, the LUTs in the user design can be reconfigured as AND gates and the flip-flops in the design can be initialized to logic ones. At this point, REV can be asserted and released, thereby forcing the values provided on the Q output terminals of the flip-flops to logic zeros. The contents of all flip-flops can be verified by executing a first readback sequence.
Errors in the readback data can be detected by a bit by bit comparison with the expected bit sequence, or by accumulating a signature on the readback data and then comparing the signature with the expected signature. An incorrect readback data stream implies that the REV terminal on one or more flip-flops is stuck xe2x80x9cinactivexe2x80x9d. If the readback data stream is correct, then the test continues. Specifically, INIT can be asserted and then released, thereby forcing the values provided on the Q output terminals of the flip-flops to logic ones.
A clock pulse can then be applied to the clock input terminal of all the flip-flops. This pulse transfers the values provided on the D input terminals of the flip-flops into the flip-flops, and thus onto their Q output terminals. The values on the Q output terminals can then be verified by executing a second readback sequence. Because all LUTs have been converted to AND gates, all flip-flop outputs were set to logic ones, and a test vector of all logic ones has been applied to the logic nets, expected readback values for the flip-flops after the clock would be all logic ones.
At this point, the actual readback data can be compared to the expected readback data. An error in the actual readback values implies that one or more interconnect in the AND gate tree, or from the tree to the flip-flops are stuck at logic zero. A faulty readback could also imply that the REV terminal on one or more flip-flops is stuck xe2x80x9cactivexe2x80x9d, or that the INIT terminal of one or more flip-flops is stuck xe2x80x9cinactivexe2x80x9d. If the readback data is correct, then no stuck-at-zero faults are detected in the programmable logic device implementing the user""s design.
A similar process is followed for the stuck-at-one test. Specifically, the LUTs in the user design can be reconfigured as OR gates and the flip-flops can be initialized to logic zeros. At this point, REV can be asserted and released, thereby forcing the values provided on the Q output terminals of the flip-flops to logic ones. The contents of the flip-flops, i.e. the values provided on the Q output terminals, are verified by executing a first readback sequence.
Once again, errors in the readback data can be detected by a bit by bit comparison with the expected bit sequence, or by accumulating a signature on the readback data and then comparing the signature with the expected signature. An incorrect readback data stream implies that the REV terminal on one or more flip-flops is stuck xe2x80x9cinactivexe2x80x9d, or that the INIT terminal of one or more flip-flops is stuck xe2x80x9cactivexe2x80x9d. INIT can then be asserted and released, thereby forcing the values provided on the Q output terminals of the flip-flops to logic zeros.
A clock pulse can then be applied to the clock input terminal of all the flip-flops. This pulse transfers the values on the D input terminals into the flip-flops, and thus onto their Q output terminals. The states of these flip-flops are then verified by executing a second readback sequence. Because all LUTs have been converted to OR gates, all flip-flop outputs were set to logic zeros, and a test vector of all logic zeros has been applied to the primary inputs, expected readback values for the flip-flops after the clock would be all logic zeros.
The actual readback data can be compared to the expected readback data. An error in the readback values implies that one or more interconnect in the OR gate tree, or from the tree to the flip-flops is stuck at logic one. If the readback data is correct, then no stuck-at-one faults are detected in the programmable logic device implementing the user""s design.
In accordance with one feature of the present invention, the block random access memory (BRAM) of the user""s design can also be controlled and observed during the fault testing. In the stuck-at-one test, the BRAM is initialized during configuration to all ones. The first test clock causes the initialization values on the input terminals of the BRAM to appear on the output terminals. Thus, all ones should appear on the BRAM output terminals. Also during the first test clock, a zero is written to address 0. The second test clock causes the zero on the input terminal at address 0 to appear on the BRAM output terminal, while a zero is re-written into address 0. Capture/readback can verify that a zero was propagated from that BRAM output terminal to a downstream flip-flop. Readback of the BRAM verifies that a zero was written into address zero and into no other cell. Control pins, such as write enable (WE) and enable (ENA), are programmed to be active low for the stuck-at-one test.
In the stuck-at-zero test, the BRAM is initialized during configuration to all zeros. The first test clock causes the initialization values on the input terminals of the BRAM to appear on the output terminals. Thus, all zeros should appear on the BRAM output terminals. Also during the first test clock, a one is written to the address designated by all ones (referenced herein as address XXX). The second test clock causes the data at location XXX to appear on the BRAM output terminals, while a one is re-written into address XXX. Capture/readback can verify that a one was propagated from that BRAM output terminal to a downstream flip-flop. Readback of the BRAM verifies that a one was written into address XXX and into no other cell(s). Control pins, such as write enable (WE) and enable (ENA), are programmed to be active high for the stuck-at-zero test.
Identifying stuck-at-one or stuck-at-zero faults can be performed during a readback operation. In one embodiment, a fault-free signature is derived from simulation. The signature produced during readback is compared to the fault-free signature. Any difference between these signatures indicates that one or more faults have been detected. Various known signatures can be used including, but not limited to, CRC and other types of compression/capture/analysis. In another embodiment, every bit in the readback data can be verified.